1. Field
Embodiments of the invention relate to dynamic configuration of a persistence provider.
2. Description of the Related Art
Object-Relational Mapping (ORM) may be described as a programming technique for converting data between application level object types implemented with object-oriented programming languages and physical data structure types, such as tables. A persistence provider may be described as performing such mapping of application level object types defined under a persistence object model that an application processes with physical data structure types defined under a physical data model (e.g., database object types in a database). The configuration of a persistence provider relies on metadata that defines the bindings between the persistence object model and the physical data model (e.g., the database).
A current problem with existing persistence providers is that they require static configuration and remain immutable once initialized. That is, as long as an application is executing, a persistence provider that is mapping underlying object structures for the application remains unchanged. For example, if a new application level object type or database object type (i.e. a table) is created during the execution of an application, then, current persistence provider implementations are not able to map the application level object type to the database object type (because the persistence provider is not able to dynamically use the updated mapping information). In order for the persistence provider to be able to map the new object type, the application execution must be stopped, the persistence provider is updated to have the new mapping information for the new object type, and the application is restarted.
Some conventional systems may require that users create a custom data model at runtime to store dynamic data. However, the application is still forced to restart, causing the persistence provider to be reinitialized.
FIG. 1 illustrates, in a block diagram, a prior art persistence technology in the context of existing persistence providers. The initial system state 100 defines one automotive part, which is an engine object that maps to the tbl_engine table in the database. The user (e.g., via an application) is able to retrieve information about this part using the configured persistence provider. In state 110, the user (e.g., via the application) adds a new automotive part type for a wheel object. The computer system updates metadata within the metadata model to include the new part type and updates the static persistence configuration. The state of the persistence provider does not reflect the updated metadata as the application has to be restarted for the persistence provider to be reinitialized with the changes. In state 120, after the application restarts, the persistence provider is able to map between the automotive parts, which are the engine object type and the wheel object type, and their respective tables, tbl_engine and tbl_wheel.
Thus, there is a need for dynamic reconfiguration of the persistence provider which does not require the application execution flow to be interrupted